home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Re Part Server.12 < prev    next >
Encoding:
Internet Message Format  |  1996-07-11  |  2.2 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Part Server
  2. Sent:        7/10/96 5:03 PM
  3. Received:    7/10/96 5:11 PM
  4. From:        Serge Froment, sfroment@odyssee.net
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. >I suspect that memory allocated by the shared library will be deallocated
  9. >when the calling process quits. This is certainly true of memory allocated
  10. >in the application zone. I believe that starting with some version of
  11. >System 7.x, temp memory allocated by an application began getting
  12. >automatically deallocated when the process was terminated. In my opinion,
  13. >it's a good idea to explicitly deallocate memory.
  14.  
  15. Would't this make quite hard to implement data caching and data sharing
  16. with different parts that view the same data?
  17.  
  18. >I suggest you try not to crash in the shared library. Your users won't like
  19. >it if you do, and will have concerns other than whether or not temp memory
  20. >was deallocated.
  21.  
  22. If I really understand your meaning, this means a background application
  23. would be a more stable implementation, right?
  24.  
  25. >The thread should belong to the process that called the shared library.
  26. >This is an educated guess - you'll have to play with this architecture to
  27. >confirm that it works.
  28.  
  29. To sum up this thread, I'd say a background application would be more
  30. stable and more easy to implement as far as memory allocation and threads
  31. are concerned. Under Copland, it could even be a preemptive task in
  32. protected memory. The only downside of this implementation is the lack of
  33. OSA support on the Windows platform.
  34.  
  35. >MacApp has excellent support for Apple Events. I know the guy that did the
  36. >MacApp OSA support. I like him. So does my fiance. As a matter of fact,
  37. >she's marrying him next weekend.
  38.  
  39. Congratulations! Tous mes voeux de bonheur! (Sorry, but I don't know the
  40. proper English words for that occasion... Just plug in the standard
  41. sentense and it should be OK :-)
  42.  
  43. >You're going to have a tough time breaking apple event support out of
  44. >MacApp. It's dependent on the MacApp TObject hierarchy, as well as the
  45. >MacApp string, stream, and color classes.
  46.  
  47. Would you consider the benefits of MacApp's AE support overweight the extra
  48. luggage?
  49.  
  50. Thanks,
  51.  
  52. Serge
  53.  
  54.  
  55.